查看原文
其他

CTO总结的管理30条军规

飒然 Hang 21CTO 2022-05-25

导读:今天是中国人民解放军建军节,军有军规,那么CTO的管理更是如此。

引言


去年以及今年由于工作需要,参加了公司请的美国管理协会的《高价值经理人》及敏捷 OKR 绩效管理的培训课程,此外也阅读了《格鲁夫给管理人的第一课》、《架构即未来》、《技术管理之巅》、《OKR:源于英特尔和谷歌的目标管理利器》几本书。


总体来看很多管理的理论其实日常自己也在实践,不过这些书的确让自己形成了自己的管理体系,能够有序有法的进行一些管理实践。本文从通用管理和技术管理两部分总结其中最让自己感到受用的几点心得。




1


   

通用管理

1.1


   

管理是推,领导是拉,领导设定目的地和通往目的地的路线图,管理设法达到目的地。

1.2


   

有效的管理是在期望的时间以可能的最低成本完成期望的品质。

1.3


   

任何工作都有产出,需要设定好指标衡量产出。疏与度量注定事情永远不会改变。

1.4


   

在一件事情越早的环节发现问题那么解决问题的成本就越小。

1.5


   

作为管理人员,要去做高杠杆率的事情,比如传授技能、知识、价值观等。

1.6


   

会议分为两种:过程导向会议和任务导向性会议。

前者是规律化的,是有必要的,可以选择效率高的方式;后者是临时的,需要尽量减少此种会议。

1.7


   

凡是有会议每个参会者都要有会议记录,可以防止开会的时候开小差。

1.8


   

全体会议一定要有一个主持者,避免陷入两人交谈。主持者最好是一个职位较高的人,可以避免同级全体综合征。

1.9


   

规律周期性的一对一沟通是非常有必要的,尤其是对于不喜欢主动沟通的属下。

1.10


   

需要建立有效沟通机制和处理问题的模式,如例会,避免下属缺乏反应问题的渠道而抱怨。

1.11


   

将员工可以划分为四象限,不同的人适用的管理方法是不一样的。

对于第一象限的人,需要提供其更多的机会,做好适当的监督即可;对于第二象限的人需要给予工作上的指导,使其能够走到第一象限;对于第三象限的人,需要解决其心理问题;对于第四象限的人则需要谈话改进。

总体来说,要做第一和第二象限的人。坚决杜绝成为第四象限的人。

1.12


   

需要根据工作成熟度的不同,适当的干涉下属工作,做好必要的监督。

1.13


   

可以把权利下放,但必须对其结果承担所有的责任。把赞扬留给团队,承认失败并公开的承担责任。

1.14


   

推行某种制度/规范的时候合理的做法是先降一个力度,等适应后再 100%推行。

1.15


   

敏捷性组织有利于可扩展的组织架构。

1.16


   

亚马逊的两张比萨饼团队:任何一个团队的规模不能大过两张比萨所能喂饱的人数,超过则需要拆分。

1.17


   

AKA(All Know All Things)。要营造一种公开、公平的氛围,不搞遮遮掩掩的事情,让大家都知道所有的事情。

1.18


   

混血性组织(组织之间有人员交叉,在不同的组织中担任不同的角色)需要双重汇报。

1.19


   

决策权利不能仅仅靠职位决定,还需要考虑专业技能和知识。

1.20


   

使用 KPI 做绩效考核如果遇到诸如难以打分、沟通不畅、抱怨强制分配等问题可以采用 OKR 做考核管理。

1.21


   

借鉴 Google,可以采取半年绩效考核(自评+他评)+OKR->总分的方式做考核。

其中采取半年的节奏是一方面是为了和 OKR 季度回顾的频率错开,另一方面对于某个重大失误可以凭借后续的其他贡献做中和;自评是需要自己陈述考核周期内的工作,他评需要被考核人邀请和自己工作相关的 n 个人给自己打分/评价;OKR 部分的最终得分只是作为参考;总分最后由直属 Leader 综合考虑几个方面打出。


2


   

技术管理

2.1


   

公司不同时期的重点技术工作

  • 初创期:开发产品原型,做技术储备

  • 发展期:保障产品升级、制定技术服务体系,处理业务部门的需求和抱怨

  • 成熟期:技术产品创新效率的提升

2.2


   

布鲁克斯定律,研发者的生产力随着团队规模的增加而减少。

努力的成本是团队规模的平方。so,技术团队的规模需要控制,人数过多的话需要考虑分拆。

2.3


   

技术需要与业务高度融合,需要培训懂业务的技术专家,切忌离开业务空谈技术。

2.4


   

十人以上技术团队可以采取轮岗来提高大家的技术热情和技术广度,但需要做好岗前培训,尤其对于技术门槛较高的岗位。

2.5


   

理解事故和问题的区别。事故需要立刻解决,而问题是要找到事故的原因。

2.6


   

以价值为导向,建立需求管理闭环,给业务需求方设定信用分,价值预估,上线后进行价值验证以判定价值达成率,从而直接影响信用分。

2.7


   

面试可以采取行为面试法,即给予实际案例看其解决问题的专业能力和思维能力。

2.8


   

技术团队超过 300 人需要建立职业发展体系、能力发展体系以及培训发展体系。

2.9


   

技术管理者需要发展三方面能力:专业能力、领导能力以通用能力(沟通能力、执行力、团队协作、责任心等)。

3


   

关于作者

飒然 Hang,《Java 工程师修炼之道》作者。重度 Java 使用者,专注于 JavaEE、系统架构、分布式等后端技术。维护博客 (https://www.rowkey.me/)

  • 目前在关注技术管理、企业效能提升相关工作。

  • 喜欢研究各种框架和开源软件的实现,偶尔自己造个轮子。

  • 推崇 Java,但也不排斥其他技术,选择最合适的才是最好的。

  • 欣赏实时求是,懂就是懂,不懂就是不懂的踏实技术人。

  • 写博客是对自己零散知识点的总结和备忘,能够帮到别人则更好。

  • 相信技术改变世界^_^


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存